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REMARKS 

Background 

In the Office Action of November 30, 2001, claims 1-44 were pending. (Actually, 
applicant has noted that no claim 37 was present. This omission and a correction are discussed 
below). Claims 16 and 17 were rejected as informal. Claims 1-6, 9, 15-20, 25, 30-35 and 38 
were rejected under 35 U.S.C. § 102(e) as being anticipated by Wootton et al. (US 6128298). 
Claims 10-14, 24-29, and 39-44 were rejected under 35 U.S.C. § 103(a) as being unpatentable 
over Wootton et al. 

Claims 7-8, 21-22 and 36-37 (claim 37 was actually mislabeled as 38) were objected to as 
being dependent on a rejected base claim but indicated as allowable if rewritten in independent 
form to include the base and any intervening claim limitations. 

Claims 16-1 7 and Other Informalities 

To address the informalities noted for claims 16 and 17, applicant has amended these 
claims as proposed by the Examiner. In addition, to correct other informalities noted by 
applicant, minor corrective amendments have been made to claim 1, claim 7 and claim 15. 
Finally to correct the misnumbering, claims 38-44 have been renumbered as claims 37-43, 
respectively. 

Rejection under 35 U.S.C. £ 102 

Claims 1-6, 9, 15-20, 25, 30-35 and 38 stand rejected under 35 U.S.C. § 102(e) as being 
anticipated by Wootton et al. (US 6,128,298). Wootton et al. describes an "IP filter 12" that is 
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essentially a conventional NAT, in fact, a particularly limited case of the conventional NAT 

design, because, as Wooten et al. state: 

The IP filter 12 accepts no connection requests from the public network 14. All 
communications between private nodes 18 and public nodes 20 are initiated by the 
private nodes. 

Wootton et al., col. 5, lines 30-33. This signals a fundamental difference between Wooten et al. 
and the present invention. Applicant's invention is designed to support and facilitate peer-to- 
peer application communication. As stated in applicant's specification: 



We will refer to the class of applications discussed herein as "peer-to-peer applications," 
which is intended to cover all applications in which two applications communicate over a 
network in an essentially symmetric fashion, where neither application is clearly a server 
or a client in the sense of an application providing a service or receiving a service, 
respectively; rather, both applications perform the same or similar functions on behalf of 
the other. 

Specification, p. 12, lines 1-5. This symmetrical nature means that the connection requests may 
originate from either peer, whether it is inside the NAT or outside the NAT, i.e., in the public 
network. Conventional NAT's, including Wootton et al.'s device, cannot, for reasons explained 
by applicant at page 10 of the specification, provide efficiently this kind of symmetrical 
connection. Applicant's invention can. 

Applicant's ability to establish peer-to-peer connections is derived in part from the 
control channel and the service request messages from an application that are made possible by 
the control channel and are answered by the address manager that communicates with an 
application over applicant's control channel. 



-7- 



Application Number: 09/661,070 



Docket: 6880 



The November 30, 2001 Office Action asserts that Wooten et al. discloses: 
"an IP handler (an address manager) provides a route[r] functionality of receiving and 
forwarding message and maintains the ARP table 34 and the Ethernet table 36; and a link 
(a control channel) in communication with IP filter 12 for receiving requests for 
communication with devices in the public network 14 from nodes 18 . . 
Office Action page 2-3. But the functions actually performed by these Wootton et al. 
components have only to do with translation of the source-destination pairs in outgoing and 
incoming IP packet messages, as detailed in Wooten et al. at col. 5, line 55 to col. 6, line 15. An 
outgoing packet from an application in Wootton et al. requires communication with public 
network devices, but the issuing application does not send a service request message for an 
address over any control channel and then receive access to an external address for 
communication to other applications. Rather, a normal EP message packet is sent to the 
translator and a header address substitution determined by the IP filter is made, then the message 
packet is sent. 

In Wooten et al. control over address association and translation remains at the level of 
the IP filter 12 and is not driven by service request messages from any application, other than an 
implied translation requirement in an IP message packet that is outgoing from an application and 
must have the internal IP address in its header translated before it is meaningful to drive the 
packet out into an address realm in which only the external, publicly assigned IP addresses are 
valid. 

The control channel and service request message structure of applicant's invention as it 
appears in independent claims 1, 15 and 30 (with some clarifying language now inserted by 
amendment), provides a significant advantage, namely control of internal-external address 
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association at, and access to external addresses to, the application level . In fact, as further 
detailed in applicant's specification at pages 15-16, there are at least three types of service 
requests that an application operating with applicant's invention can make by communicating a 
service request message over the control channel to the address manager 324: 

First, a requesting application can present an internally-valid address (either an 
originating address or a terminating address), and ask the address manager 324 to provide 
an externally valid address paired with the internally valid address and give the address 
translation section 322 access to this pairing. This can be done so that the address 
translation section 322 will use this correspondence as its translation rule for incoming 
and outgoing message packets. 

Second, an application may cause the address manager 324 to add additional or more 
complex translation rules to those used in the NAT 320, going beyond simple 
internal/external pairings. For example, instead of just performing an unconditional 
substitution of a corresponding internally-valid destination address or port for a specified 
externally- valid destination address or port found in an incoming message, a more 
complex translation rule can be built by the address manager 324 at an application's 
request. . . . 

Third, an application could specify to the address manager 324 required or desired 
characteristics for an externally-valid address requested for association with an internally- 
valid address. . . . 
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The present application, viewed in this context, may be seen as explicitly modifying the 
conventional NAT device and the device Wootton et al. describe to provide an address manager 
324 and control channel 350 that together allow an application to perform certain out-of-band 
service communications, to receive from the NAT external address information normally not 
available in a private network "behind" the NAT. 

To the extent Wooten et al. teach anything of this nature, it might be Wootton et al.'s 
User Interface 42. Wooten et al.'s User Interface 42 is described as permitting configuration of 
the IP filter and viewing and displaying certain IP filter data. But that User Interface 42 teaches 
against applicant's approach, because it teaches interaction between an operator and the IP filter 
12, not between a program/application and the IP filter 12. In addition, there is no teaching that 
the Wootton et al. User Interface 42 can handle a service request message of the kind that the 
control channel of applicant's invention receives from an application seeking an address it can 
use to establish peer-to-peer communication. Applicant's modification to the conventional NAT 
device empowers applications and enables a broad class of applications, including IP telephony, 
certain instant messaging architectures, general peer-to-peer application communications. 

Thus, it is respectfully submitted that Wooten et al. wholly fail to anticipate the address 
manager, service request message and control channel features as claimed in amended 
independent claims 1, 15 and 30. Claims 2-6, 9, 16-20, 25, 31-35 and 38 (now renumbered as 
claim 37) are dependent on one of claims 1,15 and 30 and contain additional elements. Thus, 
these claims are also not anticipated, a fortiori in view of their additional elements. 
Reconsideration and removal of the rejection of claims 1-6, 9, 15-20, 25, 30-35 and 38 (now 
renumbered as claim 37) based on Section 102 are respectfully requested. 
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Rejection under 35 U.S.C. $ 103 

Claims 10-14, 24-29, and 39-44 were rejected under 35 U.S.C. § 103(a) as being 
unpatentable over Wootton et al. For the reasons discussed above, the Wooten et al. patent 
contains significant teaching deficiencies relative to the subject matter of the base claims 1,15 
and 30, underlying claims 10-14, 24-29, and 39-44 (now renumbered as claims 38-43, 
respectively). These deficiencies are so severe that, for the same reason that Wootton et al. fails 
to anticipate the base claims rejected under Section 102, it also fails to make obvious any of 
dependent claims 10-14, 24-29, and 39-44 (now renumbered as claims 38-43, respectively). 



It is respectfully submitted that this application now stands in allowable form and 
reconsideration and allowance of all pending claims (1-43 as renumbered) are respectfully 
requested. 

It is believed that no further claim fees are due in connection with this response; however, 
if so, the Office is hereby authorized to charge Deposit Account 04-1420 for any fees due. 



Conclusion 
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Attached hereto is a marked-up version of the changes made to the specification and 



claims by the current amendment. The attached page is captioned "Marked-up Version 



Showing Changes. 



Respectfully submitted, 



DORSEY & WHITNEY LLP 



Stuart R. Hemphill (Reg. No. 28,084) 
Suite 1500 

50 South Sixth Street 
Minneapolis, MN 55402-1498 
(612) 340-2734 
Attorneys for Applicant 



Date: 
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MARKED-UP VERSION SHOWING CHANGES 



IN THE SPECIFICATION 
On page 3, please change the sentence Beginning online 8 to read as follows: 
The NAT may have assigned address X, stream A to a specific data stream for one application, 
while address X [A,] streams B and C belong to two different, other applications. 

IN THE CLAIMS 

Please amend the claims as follows: 

1. (Amended) A network address translation device for facilitating message packet 
communication between a first application in a first address realm arid a second application in a 
second address realm comprising: 

an address translator for translating an address valid in the first address realm into an address 

valid in the second address realm based on a translation rule and for translating the address valid 

in the second address realm into the address valid in the first address realm; 

an address manager for establishing a translation rule by associating an address valid in the first 

address realm with an address valid in the second address realm; and 

a control channel communicating with the address manager for receiving from the first 

application a service request message for an address valid in the second address realm to be 

associated with a specified address valid in the first address realm and for providing the first 

application access to the requested address valid in the second address realm to facilitate the first 

application's communication of the address valid in the second address realm as message packet 

data to the second application. 
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7. (Amended) The network address translation device of claim 1, wherein the address manager 
controls address translation by establishing rules for the translation of address information in an 
inbound message packet to occur or not occur in response to the presence or absence of specified 
originating address information [that] in the message packet. 

15. (Amended) A method for facilitating message packet communication between a first 
application in a first address realm and a second application in a second address realm 
comprising: 

providing the first address realm with a network address translation device having an address 
translator for translating an address valid in the first address realm into an address valid in the 
second address realm based on a translation rule and for translating the address valid in the 
second address realm into the address valid in the first address realm; 
providing an address manager in communication with the address translator for establishing a 
translation rule by associating an address valid in the first address realm with an address valid in 
the second address realm; 

providing a control channel communicating with the address manager; [and] 
receiving at the address manager from the first application a service request message for an 
address valid in the second address realm to be associated with a specified address valid in the 
first address realm; and 

providing the first application access to the address valid in the second address realm to facilitate 
the first application's communication of the address valid in the second address realm as 
message packet data to the second application. 
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16. (Amended) The method of claim 15 wherein the step of receiving a [the] request for an 
address valid in the second address realm comprises receiving a request by the first application 
for a terminating address. 

17. (Amended) The method of claim 15 wherein the step of receiving a [the] request for an 
address valid in the second address realm comprises receiving a request by the first application 
for an originating address. 

30. (Amended) A system for establishing message packet communication between a first 
application in a first address realm and a second application in a second address realm, wherein 
the first address realm has an address translator for translating an address valid in the first 
address realm into an address valid in the second address realm based on a translation rule and 
for translating the address valid in the second address realm into the address valid in the first 
realm, comprising: 

an address manager for establishing a translation rule by associating an address valid in the first 
address realm with an address valid in the second address realm; 
a control channel communicating with the address manager; and 

software operatively associated with the first application for communicating to the address 
manager a service request message for an address valid in the second address realm to be 
associated with a specified address valid in the first address realm, for receiving access to the 
requested address valid in the second address realm, and communicating the address valid in the 
second address realm as message packet data to the second application. 
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Please renumber the following claims as indicated: 

[38]37.The system of claim 30, wherein the address manager controls address translation by 
establishing rules for the translation of address information in an inbound message packet 
whereby translation occurs under a first rule or under a second rule in response to the presence or 
absence of specified originating address information in the message packet. 

[39]38.The system of claim 30, wherein the communication facilitated is peer-to-peer 
application communication. 

[40]39.The system device of claim 30, wherein the address translator performs translation with a 
rule stored in memory accessible by the address translator. 

[41]40.The system of claim 30, wherein the address manager establishes a rule stored in memory 
accessible by the address translator. 

[42]4LThe system of claim 30, wherein at least one translation rule is a rule pairing an address 
in the first address realm with an address in the second address realm. 

[43]42.The system of claim 30, wherein the address manager establishes a translation rule that 
forces an association with a destination address in a transit network. 
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[44]43.The method of claim 30, wherein the address manager establishes a translation rule that 
forces at least a portion of the communication between the first application and the second 
application to pass through a specified network. 
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